i/1 


4fo-Ai 82  252  MANAGEMENT  MAINTENANCE  AND  UPKEEP  OE  THE  BASELINE  COMO 
III  AIR  DEFENSE  MO  <U>  ARMS'  MISSILE  COMMAND  REDSTONE 
ARSENAL  AL  SVSTEMS  ANALYSIS  AND  C  E  COLVIN  29  OCT  96 
UNCLASSIFIED  AMSMI/TR-OR-02-86  SBI-AD-E950  832  F/G  15/3  2  NL 


AD- A 182  252 


eiu  fiLt  uiEi 


TECHNICAL  REPORT  0R-02-86 


MANAGEMENT*  MAINTENANCE,  AND  UPKEEP  OF  THE 
BASELINE  COMO  III  AIR  DEFENSE  MODEL 
OCTOBER  1984  -  SEPTEMBER  1985 


BY 


V 


CHARLES  E.  COLVIN 


20  OCTOBER  1986 


_ _ _ L 

j  1 

Roc#«rfcor»«  Arm* 

»na/, 

U  / 

Ala.bG.msL  35898-5000 

/ 

r 


APPROVED  FOR  PUBLIC  RELEASE; 
DISTRIBUTION  UNLIMITED 


SYSTEMS  ANALYSIS  DIVISION 
SYSTEMS  ANALYSIS  AND  EVALUATION  OFFICE 
U.  S.  ARMY  MISSILE  COffiAND 
REDSTONE  ARSENAL,  ALABAMA  35898-5060 


POflM  1031,  1  NOV  >4  PREVIOUS  EOITION  MAY  BE  USED 


5  20  .002 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  This  RAGE  (Phan  Data  Entarad) 


|  REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMBER 

Technical  Report  0R-02-86 

RECIPIENT'S  CATALOG  NUMBER 

- 

4.  TITLE  (and  Subtltla) 

Management,  Maintenance,  and  Upkeep  of  the 
Baseline  COMO  III  Air  Defense  Model 

V  Type  OF  REPORT  •  PERIOD  COVEREO 

Final 

October  1984  -  September  1985. 

performing  org.  REPORT  NUMBER 

7.  AUTHORO) 

CONTRACT  or  GRANT  NUMBER!1  a)  ” 

Charles  E.  Colvin 

None 

S.  PERFORMING  ORGANIZATION  NAME  AND  AOORESS 

Systems  Analysis  Division 

Systems  Analysis  and  Evaluation  Office 

U.S.  Army  Missile  Command,  Redstone  Arsenal,  AL 

It.  CONTROLLING  office  NAME  ANO  AOORESS 

12.  REPORT  OATE 

See  9  Above 

IS.  NUMBER  OF  PAGES 

|  14.  MONITORING  AGENCY  NAME  A  AOORES&7/  different  from  Controlling  Office) 

IS.  SECURITY  CLASS,  (of  thte  report) 

See  9  Above 

UNCLASSIFIED 

ISa.  DECLASSIFICATION  DOWNGRADING 
SCHEDULE 

IS.  DISTRIBUTION  STATEMENT  (al  (Ala  Rapart) 

r i  t  i 

_  APPROVED  FOR  PUBLIC  RELEASE; 

*"  DISTRIBUTION  UNLIMITED 

• 

1  17.  DISTRIBUTION  STATEMENT  (ol  tho  mbmtrmct  entered  In  Block  20.  If  different  from  Report)  1 

None 

it.  supplementary  notes 

None 

’B.  KEY  WORDS  fConfimas  on  reeeree  eide  it  neceeeery  end  Identity  by  block  number) 

Air  Defense  Simulation  Methodology 

Simulation  Model  Managment 

COMO  III  Model  Management 

ZG.  ABSTRACT  rConbu.  a  ravaraa  M  H  iww — y  mad  Identity  by  block  numb. r) 

This  report  contains  a  review  of  all  COMO  Model  Management  and  Maintenance 
efforts  accomplished  by  the  MICOM  Como  Model  manager  during  the  period  of 
October  1984  -  September  1985. 

DO  « '.2"  1473  corn  on  of  *  nov  «s  is  obsolete 

WA"  _ UNCLASSIFIED _ 

SECURITY  CLASSIFICATION  of  This  PA'.E  'Run  Data  Er.frad) 

1 


_ UNCLASSIFIED _ 

HCUWTY  CUAMiriCATIQW  Or  fHH  EAOKQWf  Dm*  tmfrl) 


CONTENTS 


Page 

SUMMARY . Ill 

I.  INTRODUCTION  .  1 

1.  General .  1 

2.  Purpose .  2 

II.  GENERAL  DISCUSSION  .  2 

1.  General .  2 

2.  Specific  COMO  Tasks .  2 

III.  REFERENCES .  15 

DISTRIBUTION  .  16 


1  v 


I.  INTRODUCTION 


1.  General 

1.1  A  MICON  COMO  Model  Management  Board  (CMMB)  was  established  In  May 
1981  to  ensure  that  this  Command  would  continue  to  be  responsive  to  both 
Its  own  Internal  air  defense  analysis  needs  and  external  air  defense  analysis 
needs . 


1.2  The  CMMB.  In  late  1981,  established  and  designated  an  ensemble  of 
existing  COMO  software  collectively  referred  to  and  known  as  the  COMO  III 
Baseline  Air  Oefense  Model  (COMO).  The  baseline  COMO  III  model  consisted 
of  the  following  software  ensemble: 

COMO  Frame 

COMO  Runtape  Assembly  Program 
PATRIOT  Weapon  Oeck 
HAWK  Weapon  Oeck 
CHAPARRAL  Weapon  Oeck 
STINGER  Weapon  Deck 
ROLAND  Weapon  Oeck 
AIRCRAFT  Weapon  Oeck 
JAMMER  Weapon  Deck 

1.3  The  MICOM  Systems  Analysis  and  Evaluation  Office  (SAAEO)  Is  a  member 
of  the  CMMB  and  also  serves  as  the  MICOM  COMO  model  manager.  Some  of  the 
major  responsibilities  and  duties  of  the  COMO  model  manager  Include  the  follow¬ 
ing  Items: 

a.  Continuous  Implementation  of  the  COMO  Management  plan. 

b.  Ensure  adequate  documentation  of  baseline  software. 

c.  Day-to-day  maintenance  and  upkeep  of  the  baseline  ensemble. 

d.  Provide  COMO  software  to  outside  agencies/groups  (Government  and 
Contractors). 

e.  Develop  and  document  new  COMO  software  as  required. 

f.  Provide  COMO  assletance  to  agencies  desiring  to  use  COMO  for  study 
purposes. 

To  accomplish  the  tasks  required  of  the  COMO  model  manager  a  support  contract 
was  awarded  via  competition  for  COMO  model  support;  SRS  Technologies  was 
the  winner  of  the  support  contract.  COMO  maintenance,  management,  and  other 
types  of  efforts  have  been  Implemented  by  separate  task  work  orders  to  the 
basic  time  and  materiel  (TAM)  contract  on  an  as-needed  basis. 


2.  Purpose 


2.1  The  purpose  of  this  report  Is  to  provide  a  compendium  of  all  COMO 
related  efforts  accomplished  by  the  COMO  Model  manager  during  the  timeframe 
of  October  84  -  September  85.  A  synopsis  will  be  provided  for  each  effort 
which  will  provide  a  general  Idea  and  understanding  of  each  effort. 

II.  GENERAL  DISCUSSION 

1 .  General 

1.1  The  COMO  baseline  software  Is  maintained  and  operational  on  a  CDC 
7600,  CYBER  74  and  CDC  6600  mainframes  In  Huntsville,  AL  belonging  to  the 
Strategic  Oefense  Conmand  and  the  U.S.  Army  Missile  Command.  All  of  the 
COMO  Modeling  efforts  contained  and  discussed  In  this  report  have  been  done 
under  the  guidelines  of  ensuring  maximum  compatibility  with  the  UNIVAC  1100/82 
mainframe  at  Ft.  Leavenworth,  ICS.  Thus  making  the  task  of  Implementation 
on  the  UNIVAC  1100/82  less  time-consuming  with  minimal  effort. 

2.  Specific  COMO  Tasks 

2.1  General  Maintenance  and  Upkeep 

2.1.1  All  simulation  software,  especially  large-scale,  force-on-force, 
"computerized  wargaming"  simulations,  require  continuous  support,  maintenance 
and  upkeep.  The  entire  COMO  baseline  ensemble  represents  over  32,000  lines 
of  FORTRAN  source  code.  With  the  COMO  Model  experiencing  a  high  use-rate 
throughout  the  air  defense  community.  It  Is  readily  apparent  that  unknown 
and  unexpected  coding  errors  and  logic  deficiencies  will  be  detected  and 
uncovered  on  a  regular  basis.  Once  found  and  fully  understood,  corrections 
to  these  errors/deficiencies  are  developed,  tested,  benchmarked  and  finally 
Incorporated  Into  the  baseline  software. 

2.1.2  As  studies  are  conducted  utilizing  COMO,  accompanied  by  detail 
analysis  of  the  land/air  battle  results,  air  defense  analysts  will  recognize 
possible  enhancements  to  specific  areas  of  the  software.  Many  times  more 
efficient  ways  of  accomplishing  an  air  defense  weapon  system  event,  function 
or  decision  are  discovered.  Implementation  of  these  enhancements  and  stream¬ 
lining  of  the  code  (1)  makes  the  software  simulate  specific  weapon  systems 
more  realistically,  (2)  ensures  compatibility  throughout  the  totality  of 
the  ensemble,  and  (3)  by  Increasing  and  Improving  logic  efficiency  computer 
execution  time  Is  speeded  up  along  with  requiring  less  main  memory. 

2.2  Merging  of  SETTER/QRADAR  Weapon  Deck  with  COMO  Baseline  Ensemble. 

2.2.1  Future  air  defense  study  requirements  identified  by  both  the  U.S. 
Army  Air  Defense  Artillery  School  (USAADASCH)  and  MICOM  elements  Indicated 
a  need  to  merge  the  SETTER/QRADAR  weapon  deck  with  the  baseline  COMO  ensemble. 
The  SETTER/QRADAR  weapon  deck  had  been  developed  earlier  by  the  Missile 


Research  Development  and  Engineering  Center.  The  SETTER/QRADAR  software 
was  merged  with  the  COMO  ensemble.  Incompatibilities  were  Isolated  and 
corrected  and  checkout  runs  made  to  ensure  that  the  SETTER/QRADAR  weapon 
deck  would  execute  properly  with  the  baseline  ensemble. 

2.2.2  A  brief  description  of  the  SETTER  weapon  system  and  SETTER 
simulation  model,  both  extracted  from  reference  1,  are  provided  for  general 
Information. 

2.2.3  The  SETTER  weapon  system  Is  a  lightweight  vehicle  attended  by 
two  personnel;  the  vehicle  driver  and  the  weapon  system  operator.  The  vehicle 
contains  multiple  target  sensor  subsystems  and  two  weapon  subsystems.  The 
sensor  subsystems  include  passive,  infrared  (IR),  television,  and  a  nonimaging 
sensor  and  observer,  typically  the  vehicle  driver.  Stinger  missiles  and 
hypervelocity  rockets  comprise  the  weapon  subsystems.  Weapon  launchers  and 
some  of  the  sensors  are  Integrated  into  a  rotating  turret  controlled  by  the 
system  operator.  This  turret  Is  located  on  top  of  the  vehicle.  Spare  weapons 
are  carried  In  storage  compartments  within  the  vehicle  and  are  manually 
retrieved  when  reloading  Is  desired. 

The  SETTER  mission  Is  to  thwart  the  advance  of  enemy  troops  and  their 
support  systems  along  a  battlefront.  The  primary  target  of  SETTER  systems 
are  helicopters  and  other  low-altitude  close  support  aircraft  along  the  front. 
Lightly  armored  ground  vehicles  within  the  immediate  vicinity  of  SETTER  may 
also  be  engaged  as  targets  by  using  the  armor  piercing  hypervelocity  rocket. 

SETTER  may  be  augmented  by  another  sensor  system,  the  Quiet  Radar  (QRADAR). 
The  radar  Is  considered  quiet  relative  to  attacking  anti -radiation  missiles 
(ARMs)  whose  objective  Is  to  knock  out  radars  by  homing  on  the  transmitter. 
Thus,  the  radar's  location  Is  not  easily  discerned  by  ARMs.  The  QRADAR  is 
located  remotely  from  SETTER  and  one  QRADAR  may  serve  several  SETTERS.  There 
must  always  be  a  clear  line  of  sight  from  the  radar  to  each  SETTER  with  which 
It  Is  associated.  On  each  rotational  sweep  the  radar  will  transmit  target 
information  to  the  SETTER  units  that  have  been  assigned  to  that  radar. 

The  SETTER  weapon  system  has  several  sensor  subsystems  which  are  presenting 
target  data  simultaneously  and,  of  necessity,  has  a  target  assignment  processor 
which  correlates,  prioritizes,  and  selects  the  single  primary  target.  On 
the  operator  console  the  SETTER  operator  has  a  visual  display  Indicating 
the  current  target.  When  an  operator  initiates  a  launch  at  the  primary  target, 
the  target  assignment  processor  will  then  present  the  next  priority  threat 
for  disposition. 

2.2.4  The  SETTER  simulation  model  Is  comprised  of  five  COMO  weapon  decks: 

SETTER 

SETTER  Track  File  Monitor 

Missile  flyout 

QUADAR 

QUADAR  Track  File  Monitor 


There  are  several  Interrelations  between  the  models.  The  SETTER  and 
QRAOAR  decks  locate  targets  In  accord  with  their  sensor  characteristics  that 
are  represented  as  track  file  entitles.  The  SETTER  and  QRADAR  track  file 
monitor  decks  perform  periodic  updates  to  maintain  an  accurate  state  vector 
on  the  targets  being  tracked.  The  missile  flyout  deck  performs  flyout  of 
the  Stinger  missile  and  contains  the  kill  assessment  logic  for  both  Stinger 
and  Spike  (hypervelocity  rocket)  weapons. 

Each  SETTER  unit  In  the  game  has  a  track  file  that  represents  the  targets 
that  have  been  detected.  Each  QRADAR  In  the  game  also  has  a  track  file  that 
represents  targets  currently  being  tracked.  A  SETTER  unit  may  be,  but  is 
not  necessarily,  linked  with  a  single  QRADAR.  When  this  linkage  exists  it 
Is  established  via  COMIL  Input  upon  Initiation  of  a  simulation  run.  The 
linkage  between  a  SETTER  and  a  QRADAR  enables  the  SETTER  to  access  the  track 
file  belonging  to  the  QRADAR  thereby  modeling  real-world  action  of  track 
data  transfer  from  a  QRADAR  top  an  associated  SETTER. 

The  SETTER  model  contains  event  routines  modeling  each  of  the  several 
SETTER  sensor  subsystems.  These  sensor  events  are  scheduled  to  operate 
asynchronously  with  respect  to  each  other  for  a  given  SETTER  unit.  When 
one  of  the  sensor  models  perceives  there  is  a  valid  target  which  should  be, 
but  Is  not  In  track,  then  the  event  routine  for  that  model  causes  a  SETTER 
track  file  to  be  created  to  represent  that  target. 

The  target  assignment  function  is  represented  In  a  distinct  event  routine 
within  the  SETTER  model  and  operates  periodically  and  Independently  of  sensor 
subsystems  activities.  The  target  assignment  activity  models  the  real-world 
SETTER  processor  action  to  determine  the  highest  priority  target  of  current 
Interest  to  the  SETTER  unit  and  then  represents  that  preferred  target  as 
a  visual  Image  on  the  SETTER  operator  console.  The  target  assignment  logic 
within  the  simulation  model  peruses  the  track  file  for  that  SETTER  and  the 
track  file  for  the  QRADAR  associated  with  the  SETTER  unit,  if  any,  to  construct 
a  candidate  target  list.  The  target  list  contains  one  target  from  each  of 
several  target  classes,  If  a  target  exists  within  that  class,  and  is 
prioritized  by  target  class.  The  target  list  will  have  null  entries  for 
the  target  classes  that  do  not  have  a  representative.  The  target  assignment 
function  will  then  schedule  a  target  engagement  sequence  for  only  the  highest 
priority  target  within  the  target  list. 

The  target  engagement  sequence  Is  composed  of  those  decisions  beginning 
with  FLIR/TV  lock  on  attempt  and.  In  a  successful  firing  sequence,  culminating 
In  a  launch  and  Intercept  of  the  target. 

The  QRADAR  operates  autonomously  with  respect  to  all  other  simulated 
units.  QRADAR  periodically  scans  for  targets  and  when  It  detects  a  target 
It  creates  a  track  file  entry  representing  that  target.  Each  QRADAR  has 
exactly  one  track  file  In  which  target  representations  are  stored.  This 
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track  file  may  be  interrogated  by  any  SETTER  unit  that  is  associated  with 
the  QRAOAR  unit.  The  QRADAR  may  drop  track  on  a  target  if  the  target  is 
acquired  only  on  intermittent  radar  sweeps.  The  control  values  for  maintaining 
and  terminating  track  on  a  target  are  input  via  COMIL  at  initiation  of  the 
simulation  run.  Track  file  maintenance  activities  such  as  target  state  update, 
track  termination,  etc.,  are  performed  via  periodic  execution  of  the  QRADAR 
track  file  monitor  simulation  model.  If  a  QRADAR  is  killed  during  the  course 
of  a  simulated  battle,  then  all  links  with  its  associated  SETTER  units  are 
severed  and  the  units  continue  to  operate  autonomously. 

A  SETTER  weapon  deck  functional  overview  of  modeled  events  is  shown 
in  figure  1. 

2.3  Incorporate  the  COPTR  (U.S.  helicopter)  Weapon  Deck  into  COMO 
Ensemble  and  Document  COPTR  Weapon  Deck. 

2.3.1  A  weapon  deck  depicting  an  attack  type  helicopter  firing  TOW 
missiles  was  developed  during  the  1978-79  timeframe  by  TRW,  Inc.  under  contract 
to  the  Army  Missile  and  Space  Intelligence  Center.  Various  organizations 
(USAADASCH,  MICOM,  USAMSIC)  utilized  this  weapon  deck  at  various  times  adding 
different  features  as  dictated  by  analysis  needs.  The  COPTR  weapon  deck 
has  been  renamed  the  "HELICOPTER"  weapon  deck  and  brought  under  management 
and  scrutiny  of  the  CMMB.  The  HELICOPTER  software  has  been  merged  with  the 
baseline  ensemble  with  no  known,  existing  Incompatibilities. 

2.3.2  A  brief  description  of  the  helicopter  system  and  HELICOPTER  weapon 
deck  Is  given  below.  SRS  Technologies  developed  a  two- volume  set  of 
documentation  for  the  weapon  deck  and  is  given  in  references  2  and  3. 

2.3.3  Helicopter  System  -  The  helicopter  system  Is  capable  of  being 
equipped  either  as  an  attack  vehicle  or  as  an  escort  scout  or  troop  carrier. 
The  primary  mission  is  to  fly  nap  of  the  earth  (NOE)  in  coordinated  teams, 
attack  SHORAD  systems  as  necessary  to  get  to  and  kill  armored  vehicles  or 
other  specially  designated  targets.  Each  team  consists  of  a  mix  of  attack 
helicopters  (AHs)  and  scouts  acting  in  dedicated  or  autonomous  modes.  Each 
active  helicopter  has  a  target  detection  and  lock-on  system  (IR,  EO,  passive 
RF),  communication  equipment  for  intra-team  coordination  and  target  handovers, 
and  a  radar  warning  receiver  for  self  protection.  The  AHs  are  equipped  with 
a  stock  of  command  guided  missiles  that  are  either  wire  guided  or  laser 
designated. 


2.3.4  HELICOPTER  Weapon  Deck  Overview-  Each  Helicopter  begins  by  flying 
NOE  along  a  preplanned  flight  path  Tn  team  formation  or  singly.  When  a 
dispersal  point  Is  reached,  each  helicopter  departs  to  its  assigned  firing 
position.  At  the  firing  position.  If  the  Helicopter  Is  a  LEADER,  SCOUT, 
or  operating  autonomously.  It  ascends  and  begins  searching  for  targets. 
Otherwise,  It  hovers  in  the  down  position  waiting  for  a  handover  from  a  SCOUT. 
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If  the  Helicopter  is  armed,  it  fires  a  guided  missile  when  a  target  is 
detected.  If  it  is  a  SCOUT,  it  hands  over  the  detected  target  to  the  two 
(2)  nearest  idle  attack  helicopters.  If  it  is  a  receiving  helicopter,  it 
ascends  (if  not  already  up)  to  acquire  the  target.  Except  when  a  missile 
is  in  flight,  the  helicopter  descends  immediately  when  it  becomes  apparent 
that  it  is  locked-onto  by  the  radar  of  an  enemy  air  defense  unit.  After 
it  has  descended  from  the  rise  position,  the  Helicopter  makes  a  lateral 
maneuver  and  ascends  again  to  acquire  another  target. 

After  exceeding  the  rise  and  fire  limit,  the  Helicopter  returns  to  NOE 
and  proceeds  to  the  regroup  point  to  await  the  arrival  of  the  rest  of  the 
formation.  The  Helicopter  formation  then  flies  the  preplanned  flight  track 
to  the  next  dispersal  point  for  firing  assignments  or  to  the  completed  mission 
location  (Go  Home  Point)  in  the  rear  area.  Figure  2  is  the  functional 
flowchart  for  the  events  and  delay  times  for  the  HELICOPTER  weapon  deck. 

2.4  Documentation  of  E-SAM  Weapon  Deck 

2.4.1  During  the  summer  of  1983  the  Systems  Analysis  Division  of  the 
Systems  Analysis  and  Evaluation  Office  at  MICOM  sponsored  the  development 
of  the  Generic  SHOMADS  weapon  deck  for  COMO  III.  The  model  development  was 
done  in  response  to  a  need  for  a  Short  Range,  Medium  Altitude  Air  Defense 
System  (SHOMADS)  identified  by  the  U.  S.  Army  Air  Defense  Artillery  School 
(USAADASCH).  SHOMADS  was  to  resolve  certain  ADA  deficiencies  noted  in  the 
USAADASCH  Mission  Area  Analysis  and  to  provide  an  ADA  system  capable  of 
operating  with  the  Air  Land  and  Close  Combat  Forces  envisioned  by  TRADOC 
in  the  Air  Land  Battle  2000  concept.  Initial  indications  showed  a  need  for 
the  SHOMAD  weapon  deck  by  early  1984  for  use  in  a  projected  SHOMAD  COEA. 
SHOMADS  has  been  renamed  the  Evolutionary  Surf ace- to-Air  Missile  System 
(E-SAM);  thus  we  have  now  an  E-SAM  COMO  Model.  The  model  has  been  used  with 
the  PATRIOT,  CHAPARRAL,  and  STINGER  COMO  III  models  for  studying  defense 
of  Corps  assets  and  in  support  of  Rapid  Deployment  Forces.  Several 
improvements  were  suggested  during  the  model  development  period  and  the  Systems 
Analysis  Division  sponsored  three  technical  upgrades.  Documentation  produced 
by  this  effort  includes  all  upgrades  and  enhancements  contained  in  the  E-SAM 
software,  see  references  4  and  5. 

2.4.2  A  brief  E-SAM  system  description  is  given  to  provide  a  clearer 
picture  of  the  system  as  modeled  in  COMO.  E-SAM  is  envisioned  as  a  replacement 
for  the  HAWK  and  CHAPARRAL  systems  as  they  are  currently  configured.  As 
such  it  will  be  a  Low  to  Medium  Altitude  system  (LOMAD)  used  in  support  of 
maneuver  forces  and  to  provide  point  defense  for  high  value/critical  assets 
throughout  the  combat  and  communications  zones.  The  system  consists  of  four 
major  components;  the  missile,  the  launcher,  the  tactical  control  element 
(TCE),  and  the  acquisition  sensor. 

2. 4. 2.1  The  Missile  -  The  missile  is  to  be  mounted  in  a  multiple-round 
cannister  that  functions  both  as  a  shipping  and  storage  container  and  as 


a  launch  tube.  It  will  be  capable  of  vertical  or  near  vertical  launch.  The 
missile  will  have  on-board  terminal  guidance  and  be  fire-and-forget  or  nearly 
flre-and-forget.  The  guidance  system  will  provide  for  inertial  guidance 
from  the  launcher  prior  to  launch  and  the  ability  to  select  among  on-board 
infrared  (IR),  radio  frequency  (RF),  and  passive  RF  (PRF)  seeker  systems 
after  launch. 

2. 4. 2. 2  The  Launcher  -  The  launcher  will  be  available  in  several 
configurations  to  permit  deployment  via  C-130  and  C- 141  aircraft.  It  will 
mount  6  to  12  missiles  and  have  an  on-board  sensor  for  target  acquisition 
and  tracking.  It  will  be  capable  of  receiving  track  data  from  other  launchers, 
netted  sensors,  the  TCE,  and  ADA  command  and  control  systems  (i.e.  SHORAD 
c2,  TSQ-73).  The  launcher  must  be  able  to  provide  track  data  to  the  missile 
before  and  after  launch  and  have  PJH,  modulated  RADAR/ADL,  and  tactical 
VHF-FM/HR-AM  transceivers. 

2. 4. 2. 3  The  Tactical  Control  Element  (TCE)  -  The  TCE  exercises  command 
and  operational  control  over  3  to  6  launchers.  It  will  receive  the  air-battle 
picture  from  its  launchers,  other  TCEs  sensors  and  the  ADA  system.  It 
will  provide  applicable  portions  of  this  picture  to  its  launchers  and  may 
provide  command,  control,  and/or  fire  direction  to  the  launcher  sections. 

2. 4. 2. 4  The  Sensor  -  The  sensor  must  have  a  range  and  altitude  capability 
which  exceeds  that  of  the  missile.  It  must  be  able  to  acquire  and  track 
the  target,  point  and  lock  the  missile  when  the  target  is  within  seeker  range, 
or  guide  the  missile  to  within  seeker  range  after  missile  launch.  The  sensor 
should  be  capable  of  acquiring  and  identifying  tracks  through  more  than  one 
means  and  from  non-cooperative  targets.  Track  data  must  be  able  to  be 
transmitted  to  the  TCE  and/or  directly  to  the  launcher. 

2. 4. 2. 5  Interoperability  -  E-SAM  will  operate  in  conjunction  with  and 
serve  to  complement  the  PATRIOT,  STINGER,  LADS,  and  SHORAD  systems.  It 
may  be  organized  in  separate  battalions  suitable  for  assignment  to  Corps 
ADA  Brigades  or  ADA  Brigades  at  echelon-above-corps  (EAC)  or  a  battery  size 
unit  may  be  incorporated  with  existing  SHORAD  Battalions. 

2.4.3  Weapons  Deck  Overview 

The  COMO  III  Generic  SHOMADS  weapon  deck  models  the  E-SAM  weapons  system. 
It  is  divided  into  four  modules.  Each  module  simulates  the  functioning  of 
one  major  system  component.  The  modules  are  (1)  Missile,  (2)  Launcher,  (3) 
Sensor  and, (4)  TCE.  The  modules  may  be  interfaced  to  model  three  operational 
modes.  Autonomous  launcher  operations  are  simulated  using  the  Launcher  and 
Missile  modules.  The  addition  of  the  Sensor  module  provides  for  input  of 
target  track  data  from  additional  sources.  The  use  of  all  four  modules 
reflects  autonomous  operation  at  the  platoon  level  with  the  TCE  providing 
command,  control,  and  fire  direction  to  the  launchers.  At  the  present  time, 
centralized  fire  direction/control  by  battery/battalion  command  echelons 
is  not  simulated  by  the  weapon  deck. 
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Initiation  of  a  game  results  in  a  general  sequence  of  events.  Launchers, 
sensors  and  TCEs  power  up  and  establish  communications  as  required  by  the 
scenario.  Launchers  and  sensors  begin  acquisition.  Track  data  is  passed 
by  the  sensor  to  the  launchers  and/or  TCEs  and  by  the  launcher  to  the  TCE. 
The  TCE  passes  correlated  track  data  and  fire  control  data  to  the  launchers. 
The  launcher  provides  target  information  to  the  missiles  and  engages  targets 
assigned  by  the  TCE  or  the  highest  priority  target  when  acting  autonomously. 
After  launch,  the  launcher  provides  target  update  to  the  missile  until  the 
missile  target  seeker  achieves  lock-on.  Once  lock-on  is  achieved,  the  missile 
continues  to  intercept. 

2.5  Assessment  of  different  COMO  Frames  and  COMO  Runtape  Assembly 
Programs. 

The  extensive  use  of  COMO  by  different  organizations  since  the  middle 
to  late  1970's  has  resulted  with  many  different  "versions"  of  the  COMO  frame 
and  runtape  assembly  programs.  COMO  users  had  become  concerned  as  to  the 
differences  between  the  versions  and  whether  or  not  any  user  had  a  "better" 
version  than  anyone  else.  The  COMO  support  contractor  was  tasked  to  perform 
an  assessment  of  the  COMO  frames  and  runtape  assembly  programs  listed  below: 

(a)  MICOM  Systems  Analysis  and  Evaluation  Office 

-  CDC  6600  @  MICOM 

-  CDC  7600  @  Advanced  Research  Center 

(b)  Research,  Development  and  Engineering  Center,  MICOM 

-  CDC  6600  @  MICOM 


(c)  Missile  and  Space  Intelligence  Center  (MSIC) 

-  CDC  7600  @  MSIC 

(d)  PATRIOT  Project  Office 

-  CDC  7600  @  Advanced  Research  Center 

(e)  U.S.  Army  Air  Defense  Artillery  School,  Ft.  Bliss,  TX 

-  CDC  7600  @  Advanced  Research  Center 

-  UN I VAC  1100/82  @  Ft.  Leavenworth,  KS 

The  contractor  was  also  directed  to  make  recommendations,  based  upon 
the  assessment,  on  developing  a  MICOM  standard  frame  and  runtape  assembly 
program.  The  assessment  and  recommendations  were  documented  and  are  contained 
In  reference  6. 

2.5.1  Assessment  Conclusions 


The  assessment  showed,  to  the  amazement  of  many,  strong  agreements  within 
and  between  the  different  CDC  frame  and  runtape  assembly  program  versions. 


2.6  Incorporation  of  TBM  Weapon  Deck  Into  Baseline  Ensemble 

A  tactical  ballistic  missile  (TBM)  COMO  weapon  deck  was  developed  by 
the  PATRIOT  Project  Office  for  analysis  needs.  This  software  allowed  TBM 
types  of  threat  to  be  included  in  the  enemy  raid  against  ground  forces. 
This  "small"  weapon  deck  was  incorporated  into  and  made  part  of  the  COMO 
baseline  ensemble  of  software. 

2.7  Benchmarking  the  COMO  III  Baseline  PATRIOT  Weapon  Deck  with  Simpler 
COMO  Generic  Models 

The  PATRIOT  baseline  weapon  deck  contains  in  excess  of  5,500  lines  of 
source  code.  A  Simplified  PATRIOT  COMO  III  (SPAT)  model  was  developed  and 

documented  in  1981  for  use  in  PATRIOT  studies  not  requiring  the  higher  fidelity 
baseline  model:  SPAT  has  approximately  2,000  lines  of  source  code. 

The  CMMB  and  other  COMO  users  became  interested  in  comparing  the  results 
of  similar  scenarios  run  on  different  PATRIOT  COMO  Models.  A  task  was 
implemented  with  the  COMO  support  contractor  to  access  and  evaluate  the 

differences  and  similarities  of  results  between  the  baseline  PATRIOT  model 

and  the  (1)  SPAT,  (2)  CAA  FOFEBA  model  and,  (3)  STC  CIAD  model  utilizing  the 

same  tactical  scenario  in  each  case.  The  results  of  the  effort  are  documented 
in  reference  7. 

2.7.1  Conclusions 

Good  comparisons  for  all  four  models  were  achieved  over  stylized 
one-on-one,  one-on-few  and  few-on-many  scenarios.  This  was  somewhat  unexpected 
due  to  large  degree  of  fidelity  between  the  four  models.  For  the  aggregated 
PATRIOT  models  (SPAT,  STC  CIAD,  CAA  FOFEBA)  close  detail  must  be  paid  to 

the  model  input  parameters  for  PATRIOT.  One  would  intuitively  expect  this 
since  fewer  input  parameters  implies  less  fidelity  of  the  weapon  system 
representation  within  the  model. 

2.8  COMO  III  Executive  Level  Documentation 

A  useful,  clear  and  concise  "executive  level"  level  of  documentation 

was  needed  for  the  COMO  III  baseline  model.  This  level  of  documentation 

should  present  to  the  reader.  In  a  non-technical  format,  basic  facts  and 

information  relative  to  the  COMO  baseline  model.  The  COMO  support  contractor 
was  tasked  to  develop  such  a  document  and  is  contained  In  reference  8.  The 
following  major  topics  were  Included  in  the  executive  document: 

(a)  What  Is  COMO  III 

(b)  COMO  III  History 

(c)  COMO  III  Structure/Size  of  COMO  III 

(d)  Users  of  COMO  III 

(e)  Modeling  of  Key  Air  Defense/Threat  Functions 

(f)  Existing  COMO  III  Weapon  Decks 


(g)  Brief  Discussion  of  Baseline  Weapon  Decks 

(h)  Related  Bibliography  of  Existing  Documentation 


2.9  COMO  III  FORTRAN  IV  -  V  Converslon/Val Idatlon 

All  CDC  7600  users  at  the  Advanced  Research  Center  were  advised  in  late 

1983  that  FORTRAN  IV  would  not  be  supported  after  November  1984.  Based  upon 

this  fact,  an  effort  was  Initiated  with  SRS  Technologies  to  convert  COMO 

III  from  FORTRAN  IV  to  FORTRAN  V.  A  significant  effort  was  exerted  in 
conducting  verification/validation  comparisons  to  ensure  that  the  FORTRAN 
V  code  was  behaving  as  the  FORTRAN  IV  code. 

2.10  SGT  YORK  Weapon  Deck  Enhancement/Documentation 

A  SGT  YORK  COMO  III  weapon  deck  had  “evolved"  during  1982  -  1984  with 
no  one  organization  claiming  to  be  the  owner/originator  of  the  software.  With 
mounted  interest  of  Including  the  SGT  YORK  weapon  system  within  the  deployed 
ground  forces,  an  effort  was  initiated  by  the  CMMB  to  ensure  adequate 

representation  of  the  production  version  of  S6T  YORK  within  the  COMO  III 
weapon  deck.  Discussions  and  meetings  were  held  with  AMSAA,  USAADASCH  and 
the  SGT  YORK  project  manager  during  the  enhancement  phase  to  ensure  that 
"all  players”  were  aware  and  satisfied  with  any  proposed  change  or  addition. 
A  SGT  YORK  user/analyst  manual,  see  reference  9,  was  developed  for  the  enhanced 
SGT  YORK  weapon  deck. 

2.10.1  A  brief  overview,  extracted  from  reference  9,  Is  provided  for 
the  SGT  YORK  COMO  III  weapon  deck. 

The  SGT  YORK  Gun  weapon  deck  contains  the  seven  critical  events 
shown  in  Figure  .  DG1  Is  the  surveillance  radar  event  and  contains 
the  threat  ordering  logic  performed  by  the  fire  control  computer 
(FCC).  It  Is  Initially  scheduled  from  the  enter  game  event  (DGO) 
and  is  rescheduled  on  a  cyclic  basis.  When  radar  target  detection 
occurs,  the  optical  search  process  (DG9)  is  terminated  and  the 
lock-on  event  (DG2)  is  scheduled  with  a  time  delay  of  DT12  seconds, 
which  allows  for  turret  slewing  to  the  target  azimuth  plus  one 
search  cycle  In  elevation  by  the  track  radar/gunner's  optics.  DG1 
constantly  monitors  the  radar  surveillance  search  volume  and  when 
a  higher  priority  target  Is  detected.  Initiates  the  necessary  target 
replacement  logic.  DG1  will  also  monitor  for  jam  strobes  if  normal 
target  detections  (range  information  available)  are  not  made  and 
will  schedule  DG2  If  a  jam  strobe  Is  detected. 

DG9  Is  the  squad  leader's  optical  search  event.  It  Is  sector 
search  centered  around  the  gun's  primary  defense  target  line  (PTL). 

The  PTL  and  sector  size  are  specified  by  COMIL  INPUT.  DG9  is 
Initially  scheduled  when  the  fire  unit  enters  the  fame  and  is 
rescheduled  cyclically  as  long  as  no  targets  are  found  by  either 
the  radar  or  optical  systems.  When  a  target  is  visually  detected, 

DG9  schedules  lock-on  (DG2)  after  a  reaction  time. 
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Figure  3.  S6T  YORK  COHO  III  MODEL 


062  Is  the  lock-on  event  by  either  the  track  radar  or  the 
optical  tracker  (with  range  via  the  laser  range  finder).  If  lock-on 
Is  successful  and  target  range  Is  available,  assessment/fire  (0G3) 
Is  scheduled.  Otherwise,  DG2  reschedules  as  long  as  the  target 
remains  alive,  visible,  approaching,  and  lies  within  the  engagement 
range  of  the  system.  The  engagement  is  cancelled  and  the  optical 
search  event  Is  re- Initiated  if  any  one  of  the  above  conditions 
are  not  met.  Individual  jam  strobe  tracks  are  only  checked  twice 
for  track  radar/optical  lock-on  before  being  dropped  and  having 
optical  search  re-initiated. 

DG3  is  the  target  assessment/fire  event.  A  burst  is  fired 
at  the  target  every  DT3F  seconds  (variable  dependent  upon  range 
and  aircraft  type)  until  a  definite  NO-GO  assessment  results  or 
the  gun  ammunition  supply  is  exhausted,  at  which  time  reload  is 
scheduled.  An  independent  combat  unit  (CU)  is  dynamically  created 
for  the  burst  in  order  to  accommodate  the  limit  of  four  events 
scheduled  from  any  one  CU  at  any  one  time. 

DG4  is  the  explode  event.  In  DG4  the  kinematic  constraints 
are  checked  and  the  random  drew  is  compared  to  PKILL  to  determine 
the  result  of  the  engagement.  If  it  is  determined  that  the  burst 
killed  the  target,  0G5  will  be  scheduled  after  time  delay  of  DT45 
seconds  to  remove  the  target  from  the  game.  DT45  is  the  kill 
assessment  time  delay. 
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